1. The Field of the Invention
The present invention is directed to transferring electronic data in a uniform manner. More particularly, the present invention relates to transferring data using a common data structure regardless of the format used to represent the data, and regardless of the transfer mechanism to be used to transfer the data.
2. Related Technology
Computing technology has transformed the way we work and play. Computers consist of hardware components such as for, example, processors and memory capability. Some of the memory capability is typically non-volatile in the sense that it retains its content when the computer loses power. For example, hard disks and CD-ROMs are each forms of non-volatile memory. Some of the memory capability is typically volatile in the sense that it loses its content when the computer loses power. For example, system memory (also commonly referred to simply as “memory”) is often volatile.
Although volatile, system memory is useful in forming runtime modules. Such runtime modules may include, for example, data structures and objects. These modules are often formed in system memory in response to software such as an operating system, an application program, or portions thereof, being executed by one or more processors. Such modules are often capable of communicating with each other to cooperatively perform tasks.
One common way of doing this is for one module (called herein a “called module”) to “expose” an interface to other modules (called herein “calling modules”). In other words, the called module publishes methods that may be called by calling modules. A calling module makes the called module perform a particular method by placing a function call to the called module. The function call follows a predetermined standard called an Application Program Interface (API). The called module may also communicate with yet other modules to form a network of modules that cooperatively perform complex actions. Such complex actions may include running a graphics-intensive computer game, performing complex engineering simulations, or managing information such as calendars, e-mails, tasks, or the like. Since computers are often general purpose, the variety and scope of complex actions that may be performed by the computer seem to be limited only by the apparent limitless imagination and skill of the software programmer.
In order to perform complex actions, modules will almost inevitably need to communicate data one with another. Often, the data is represented by a data structure that follows a predetermined pattern or “schema”. This allows the module that receives the module to not just read the data, but also determine the meaning of the data so long as the module recognizes the predetermined pattern.
One way of patterning data is to form a hierarchically-structured tree of name-value pairs. One convenient way of doing this is to represent the data as an eXtensible Markup Language (XML) document. There are various ways to transfer an XML segment from one module to another. Currently known transfer mechanisms include transferring the XML segment as a UTF-8 string, Unicode string, or DOM object. Also, the XML segment may be transferred using interfaces such as an, ISaxContentHandler interface.
Each of these transfer mechanisms is well-known to one of ordinary skill in the art and has relative advantages and disadvantages. For example, let us compare transferring strings versus transferring DOM objects. DOM objects take processing resources to create. However, once created, they are useful as they contain embedded parsing information. On the other hand, strings take very little processing resources to create. However, strings contain no embedded parsing information. Accordingly, the selection of a transfer mechanism is important when transferring an XML segment as the selection may have a real impact upon the efficiency of the computer system.
When a software programmer designs a software module to transfer an XML segment, the source code that the software programmer writes typically depends on the transfer mechanism that is to be used to transfer the XML segment. For example, there may be APIs focused on transferring strings between modules, and other different APIs focused on transferring XML through an ISAXContentHandler Interface. Such non-uniformity adds complexity to the source code and thus increases the cost and potential for error associated with authoring source code.